United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
I nilid Stall-, Patent and Trademark Office 

Address: COMMISSIONER FOR PATENTS 



APPLICATION NO. 



10/500.739 



FILING DATE 



FIRST NAMED INVENTOR 



Yong Kin I Michael I ( )ng 



ATTORNEY DOCKET NO. CONFIRMATION NO. 



26016.0004U1 



23859 7590 

Ballard Spahr LLP 
SUITE 1000 

999 PEACHTREE STREET 
ATLANTA, GA 30309-3915 



ROBINSON, KITO R 



PAPER NUMBER 



DELIVERY MODE 



Please find below and/or attached an Office communication concerning this application or proceeding. 

The time period for reply, if any, is set in the attached communication. 



PTOL-90A (Rev. 04/07) 



l/ffflrC? nVrliUli Otfff Iff ids y 


Application No. 

10/506,739 


Applicant(s) 

ONG, YONG KIN (MICHAEL) 


Examiner 

KITO R. ROBINSON 


Art Unit 

3695 





- The MAILING DATE of this communication appears on the cover sheet with the correspondence address — 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )KI Responsive to communication(s) filed on 17 September 2010 . 
2a )^ This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) |EI Claim(s) 1,3-14, 16-45,47-52, 72-77 and 79-92 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) E] Claim(s) 1,3-14,16-45,47-52,72-77 and 79-92 is/are rejected. 

7) ^ Claim(s) 87-92 is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) Q The specification is objected to by the Examiner. 

10) ^ The drawing(s) filed on 03 September 2004 is/are: a)^ accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) ^ Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)E| All b)D Some * c)D None of: 

1 Certified copies of the priority documents have been received. 

20 Certified copies of the priority documents have been received in Application No. . 

3.Q Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) ^| Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-41 3) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

3) Information Disclosure Statement(s) (PTO/SB/08) 5 ) □ Notice of Informal Patent Application 
Paper No(s)/Mail Date 09/30/2010 . 6) □ Other: . 



PTOL-T26 d (Rev e 08-06r 



Office Action Summary 



Part of Paper No./Mail Date 20101028 



Application/Control Number: 10/506,739 
Art Unit: 3695 

DETAILED ACTION 



Page 2 



Status of Claims 

1. This action is in reply to the amendment filed on 17 September 2010. 

2. Claims 2, 15, 46, 53-71 & 78 have been canceled. 

3. Claims 87-92 have been added. 

4. Claims 7 & 86 have been amended. 

5. Claims 1, 3-14, 16-45, 47-52, 72-77 and 79-92 are currently pending and have been examined. 

Information Disclosure Statement 

6. The Information Disclosure Statements filed on 18 October 2004, 14 December 2004, 02 March 
2009, 02 April 2010 & 30 September 2010 have been considered. An initialed copy of the Form 1449 
is enclosed herewith. 

Priority 

7. Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been 
placed of record in the file. 

Claim Objections 

8. Claims 87-92 are objected to because of the following informalities: Amendments to a claim must be 
made by rewriting the entire claim with all changes (e.g., additions and deletions) as indicated in this 
subsection, except when the claim is being canceled. Each amendment document that includes a 
change to an existing claim, cancellation of an existing claim or addition of a new claim, must include 
a complete listing of all claims ever presented, including the text of all pending and withdrawn claims, 
in the application. The claim listing, including the text of the claims, in the amendment document will 
serve to replace all prior versions of the claims, in the application. In the claim listing, the status of 
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every claim must be indicated after its claim number by using one of the following identifiers in a 
parenthetical expression: (Original), (Currently amended), (Canceled), (Withdrawn), (Previously 
presented), (New), and (Not entered). Claims 87-92 are not properly labeled. Appropriate correction 
is required. 

Response to Arguments 

9. Applicant's arguments received on 17 September 2010 have been fully considered but they are not 
persuasive. Referring to the previous Office action, Examiner has cited relevant portions of the 
references as a means to illustrate the systems as taught by the prior art. As a means of providing 
further clarification as to what is taught by the references used in the first Office action, Examiner has 
expanded the teachings for comprehensibility while maintaining the same grounds of rejection of the 
claims, except as noted above in the section labeled "Status of Claims." This information is intended 
to assist in illuminating the teachings of the references while providing evidence that establishes 
further support for the rejections of the claims. 

10. With regard to the limitations of claim 1, 48, 49 & 50, Applicant argues "It is respectfully submitted that 
Ice does not contain a disclosure of the all of the features said to be present by the examiner. It is 
apparent that the examiner has equated the single use transaction request identification (of the claim) 
with the single use credit card number (of the reference). The transaction manager (of the claim) 
seems to have been equated to the payment server (of the reference). Because the single use credit 
card number has been equated to the single use transaction request identification it can not also be 
the received user identifier (of the claim). While the address may be regarded as a user identifier, it is 
not received by the payment server (or the gateway server) in a payment request as required by 
claim 1 (and is therefore not the "received user identifier" referred to in the claim)." 

The Examiner respectfully disagrees. First, the Examiner acknowledges the inadvertent missing 
of claims 48 & 49 in the heading and has added the missing claims to the heading. In reference to claims 
1, 48, 49 & 50 the Ice reference disclose two processes generating the single use credit card number and 
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the approval of the transaction. "When the user of the computer terminal 10 alternately wishes to 
purchase a product or service over the public network 12 using a debit card 32, he swipes the debit card 
32 through the slot 30 in the encryption unit 26" (column 4, lines 54-58). "At this point, the data 
transferred from the personal computer 14 the payment server 34 includes both encrypted 
information identifying the credit card number and unencrypted information specifying the serial 
number of the encryption unit 26 and the address to which the transaction is to be billed" (column 
4, lines 25-30). "The payment server 34 then generates a single-use credit card number, which is 
stored in a data structure 50 within the database 36, along with the data received from the personal 
computer 14" (column 4, lines 54-57). "The single-use credit card number is also returned to the personal 
computer 14 over the public network 12" (column 4, lines 60-62). "After the personal computer 14 
receives the single-use credit card number, this number is placed in window of the browser program 
executing within the personal computer 14 where the credit card number would otherwise be placed. 
While the single-use credit card number 52 is preferably handled within the personal computer 14 by 
software executing in the processor 20, the new number may alternately be displayed for the user to type 
as part of his order. Next, the order is transferred over the public network 12 to a web site server 54 
operated by the merchant from which the goods or service is being ordered. The order is placed using the 
single-use credit card number 52 received from the payment server 34, along with other data identifying 
the object to be purchased, etc., by transmission over the public network 12 between the personal 
computer 14 and the merchant's web site server 54" (column 5, lines 1-15). 

It is clear that the single use transaction request identification (of the claim) is equated with the 
single use credit card number (of the reference). The transaction manager (of the claim) is equated with 
the payment server. The user identifier (of the claim) is equated with the address to which the transaction 
is to be billed and serial number (of the reference). In column 5, lines 46-50, the payment server by way 
of the gateway server, receives the single use credit card number (single use transaction request 
identification of the claim) to compare. The payment server already received the a user identifier 
(address) and value (inherent) from the initial start of the transaction from the personal computer. 
Therefore, Applicant's arguments are not persuasive. 
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Applicant further argues "The gateway server of Ice does not: "(determine) the validity of the 
received payment request by checking the validity of the received transaction request identification and 
whether the received transaction request identification is stored in a relationship with the received user 
identification ". Instead the payment server checks the validity of the single use single use credit card 
number and whether the received transaction request identification is stored in a relationship with the 
serial number and in turn with the decrypted credit card number and address, (neither of which were 
received in the payment request)." 

The Examiner respectfully disagrees. In column 5, lines 50-56 discloses "Next, the payment 
server 34 compares the single-use credit card number 52 with data stored within its database 36 in data 
structure 50. When a match is found, the payment server reads the serial number associated with the 
single-use credit card number in the data structure 50, and searches the data structure 48 for this serial 
number. When this serial number is found in the data structure 48, the payment server 34 uses the 
cryptogram associated with the serial number in the data structure 48 to decode the encrypted data 
associated with the single-use credit card number in the data structure." The validity of the payment 
request is checked by the payment server which matches the single use credit card number with the 
stored number and serial number then decodes the data structure which contains the additional 
information provided by the personal computer (actual credit card number, serial number and billing 
address). Therefore, Applicant's arguments are not persuasive. 

Applicant further argues, "It is the gateway server that proceeds with a conventional credit card 
transaction (after the payment server has substituted the single-use credit card number with the actual 
credit card number) and not the payment server. Therefore, it is the gateway server and not the payment 
server that: "(receives) at the transaction manager apparatus (the payment server) confirmation of the 
transfer from the financial institution when the transfer is performed." 

The Examiner respectfully disagrees. In column 7, lines 20-24 disclose "Upon approval of the 
debit card transaction, the bank computer 64 returns an approval indication to the payment server 33. 
The payment server 33 then returns an approval indication to the gateway server 58, which in turn notifies 
the merchant's web site server 54." Therefore, applicant's arguments are not persuasive. 
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11. With regard to the limitations of claim 14 Applicant argues "With regard to claim 14, this requires the 
payment request to further comprise a component provided by the registered user and the transaction 
manager apparatus receives the user provided component from the user independently from and 
before receiving the purchase request, and storing of the user provided component in the storage in a 
relationship with the identifier of the registered user. This is not disclosed in Ice despite the assertion 
that it is disclosed by the user swiping the card, because the user provided component is not provided 
in the payment request. Only the single use credit card number (the value and merchant ID) are 
provided in payment request." 

The Examiner respectfully disagrees for the same reason stated above. During the initial card 
reading the user provides the user components first, its not until after the actual card number is replaced 
with the single use number which is then provided to the payment server by way of the gateway server is 
the payment request completed. 

12. With regard to the limitations of claim 16 Applicant argues "With regard to claim 16, this requires 
comparing the user provided component received in the payment request with the stored user 
provided component to determine the validity of the payment request. Since the payment request 
does not include the user provided component this comparison can not occur." 

The Examiner respectfully disagrees for the same reason stated above. The validity of the 
payment request is checked by the payment server which matches the single use credit card number with 
the stored number and serial number then decodes the data structure which contains the additional 
information provided by the personal computer (actual credit card number, serial number and billing 
address). 

13. With regard to the limitations of claim 17 & 28 Applicant argues "Claim 17 requires the user provided 
component comprise a secret identification of the user known to the registered user. Ice discloses 
providing a PIN to the payment server, but this is a precursor step and not part of a payment request 
and Claim 28 requires a user provided component that comprises a secret identification of the user 
known to the registered user and recorded in the financial institution. Again while providing a PIN to 
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the payment server is disclosed as a precursor step, there is no disclosure of the PIN being provided 
in a payment request." 

The Examiner respectfully disagrees for the same reason stated above. The user provides a PIN. 

14. With regard to the limitations of claim 18 Applicant argues "Claim 18 requires a transaction limit and 
with a transaction limit override password. While Robinson may describe a transaction limit, there is 
no disclosure of a transaction limit override password. 

The Examiner respectfully disagrees. Further details of the override function is disclosed in the 
incorporated reference (09/765,789) which disclose in paragraph 0058 real time authorization by the 
primary account holder of transactions that exceed a predetermined threshold. The primary card hold 
must request approval of the transaction via a communication device before the transaction can be 
approved. 

15. With regard to the limitations of claim 26 Applicant argues "Claim 26 requires combining the 
transaction request identification and the user provided component by hatching, Ice makes no 
disclosure of hatching." 

The Examiner respectfully disagrees. Column 4, lines 7-11 do not explicitly say hatching 
however the unencrypted number is combined with the PIN to create a 64 character string which is 
synonymous with the definition of hatching as applicant disclosed in claim 26. 

Claim Rejections - 35 USC § 103 

16. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections 

set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

17. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that 
are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are 
summarized as follows: 
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1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness or 
nonobviousness. 

18. Claims 1-4, 6-12, 14, 16-32, 34-37, 43-45, 47-52, 72-77, 79-82, 84-90 & 92 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ice US Patent Number 6,598,031 B1 in view of Robinson 
US 2003/0061 172 A1. 

As per claim 1, 48, 49 & 50 

Ice discloses: 

• generating a single use transaction request identification with a transaction manager (column 4, 
lines 54-57) 

• storing the generated single use transaction request identification in a relationship with an 
identifier of a registered user and banking information of the registered user in a storage of the 
transaction manager apparatus; (column 4, lines 54-57) 

• sending the generated single use transaction request identification to the registered user from the 
transaction manager (column 4, lines 60-63); 

• receiving at the transaction manager apparatus a payment request comprising a received user 
identifier, a value and information for making a fund transfer of the value from the registered user 
identified by the received user identifier to an identified recipient, the payment request also 
including a received transaction request identification; (column 5, lines 43-53 & column 5, lines 
61-64) Ice does not explicit state a value but it is inherent in the teaching that the transaction 
cannot be approved without a value; 

• determining the validity of the received payment request by checking the validity of the received 
transaction request identification and whether the received transaction request identification is 
stored in a relationship with the received user identifier with the transaction manager apparatus; 
(column 5, lines 43-56); 

• disabling re-use of the single use transaction request identification (Column 6, lines 5-9) 
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• sending an EFT request to a financial institution system to transfer the value in funds from the 
registered user to the recipient, only if the received payment request is valid, the EFT request 
including the banking information, (column 5, lines 61-65); 

• receiving at the transaction manager apparatus confirmation of the transfer from the financial 
institution when the transfer is performed (column 5, lines 61-65) 

• sending a confirmation message from the transaction manager apparatus to one or more of the 
group consisting of the user and the recipient (column 5, lines 61-65). 

Ice does not disclose the following, however Robinson does: 

• a registered user (Abstract) 

• such that the financial institution is able to check whether sufficient funds are present in a user's 
financial institution account and, in the event that sufficient funds are present the financial 
institution is able to perform the transfer according to the EFT request (paragraph 0074); 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to register and verify the user's and merchant's identity to the system. 

As per claim 3, 51 & 52 

Ice discloses: 

• the transaction request identification is a random number (paragraph 0040). 

As per claim 4 

Ice discloses: 

• the transaction request identification is generated using a formula (paragraph 0025). 



As per claim 6 

Ice discloses: 
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• the payment request comprises a component provided by the registered user (Column 1, lines 
2-3). 

As per claim 7 

Ice discloses: 

• the recipient is provided with a further combination of the transaction request identification and 
the user provided component (column 5, lines 61-65). 

As per claim 8 

Ice discloses: 

• the banking information related to the transaction request identification includes a credit card or 
debit card number, a card expiry date and a cardholder name (column 1, lines 43-46). 

As per claim 9 

Ice discloses: 

• the banking information includes a bank account number (column 5, lines 21 -24). 

As per claim 10 

Ice discloses: 

• the banking information includes bank account type and bank account holder information 
(paragraph 0036: Ice does not explicitly disclose bank account type however it is inherent 
that if the verification system checks the validity of the credit card indicating whether the 
type of bank account is valid). 

As per claim 11 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of registering an unregistered user prior to the generation of the transaction request 



Application/Control Number: 10/506,739 Page 1 1 

Art Unit: 3695 

identification. However, Robinson, in the Abstract discloses "System users register at least one biometric 
identifier, personal and/or business identity -verifying data, and financial account information." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick and easy way to 
verify the user. 

As per claim 12 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of registration of the user comprises creating of a transaction manager user account, and the 
identifier of the registered user is a transaction manager account number allocated by the transaction 
account manager. However, Robinson, in paragraph 0036 discloses "one or more financial account (e.g. 
checking, credit, or value); and a consumer may choose a SID from any of the previously listed numbers, 
may create a SID, provided the SID is unique to the central database 102, or may choose from system 
suggested ID numbers." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick and easy way to 
set up a user account and verify the user. 

As per claim 14 

Ice discloses: 

• the transaction manager apparatus receiving the user provided component from the user 
independently from and before receiving the purchase request and storing the user provided 
component in the storage in a relationship with the identifier of the registered user (column 3, 
lines 66-67, column 4, lines 16-20, column 4, lines 50-53, column 4, lines 54-57 & column 4, 
lines 60-62). The user swiping the card provides the first 16 digits before receiving and storing 
the purchase request and the generation of the single use number. 
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As per claim 16 

Ice discloses: 

• wherein determining the validity of the received payment request further comprises comparing the 
user provided component received in the payment request with the stored user provided 
component and determining that the payment request is invalid when the user provided 
component is not the same as or based on the stored user provide component (column 5, lines 
47-53) 

As per claim 17 

Ice discloses: 

• the user provided component comprises a secrete identification of the user known to the 
registered user (column 3, lines 66-67, column 4, lines 7-11) 

As per claim 18 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of storing the transaction request identification in association with a transaction limit, and with a 
transaction limit override password wherein the transaction manager apparatus does not send the EFT 
request if the value is above the transaction limit and the transaction limit override password is not 
received in the payment request. However, Robinson, in paragraph 0087 discloses "Such pre-set 
parameters may include but are not limited to consumers setting a limit on how much may be spent out of 
a specific account." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick and easy way to 
provide added security to the user. 
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As per claim 19 

Ice discloses: 

• sending the registered user another single use transaction request identification from the 
transaction manager apparatus upon receipt at the transaction manager apparatus of a request 
by the registered user (column 6, lines 5-9) 

As per claim 20-22 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of the registering a merchant with the transaction manager apparatus as one of a number of 
possible recepients, registration of the merchant comprises the transaction manager apparatus providing 
the merchant with a merchant identification and the transaction manager apparatus storing merchant 
banking information in a relationship with the merchant identification, wherein the purchase request 
received by the transaction manager apparatus includes the merchant identification. However, Robinson, 
in at least Paragraph 0037 discloses "Merchant accounts comprise information useful for authenticating a 
merchant, associating a merchant with a financial account, and completing transactions. By way of 
illustration and not as a limitation, a merchant account may comprise a SID, merchant location, and a 
phone number; a list of terminal ID numbers (TIDs) of the terminals designated to perform system 
functions; one or more financial accounts; and enrollment and transaction approval/decline parameters." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to register and verify the merchant identity to the system. 

As per claim 23 

Ice discloses: 

• the registered user requesting purchase of a product or service having the value from the 
merchant and the merchant providing the payment request to the transaction manager apparatus 
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(column 5, lines 43-53 & column 5, lines 61-64) Ice does not explicit state a value but it is 
inherent in the teaching that the transaction cannot be approved without a value; 

As per claim 24 

Ice discloses: 

• the registered user nominating an item for purchase and a merchant device of the recipient 
constructing the purchase request including determining the value in the purchase request based 
on the nominated item (column 5, lines 12-16). Ice does not explicit state a value but it is 
inherent in the teaching that the transaction cannot be approved without a value. 



As per claim 25 

Ice discloses: 

• checking the validity of the received transaction request identification in the payment request 
comprises checking whether the transaction request identification received in the payment 
request is the same as or derived from the stored transaction request identifier stored in the 
relationship with the user identifier (column 5, lines 43-56); 

As per claim 26 

Ice discloses: 

• combining the transaction request identification and the user provided component by hatching the 
transaction request identification and the user provided identification component (column 4, lines 
7-11). 
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As per claim 27 

Ice discloses: 

• disabling of the use of the transaction request identification is comprises removing the 
relationship between the transaction request identification and the user's transaction manager 
account number (column 6, lines 33-42) 

As per claim 28 

Ice discloses: 

• user provided component comprises a secrete identification of the user known to the registered 
user and recorded in the financial institution (column 4, lines 7-1 1 : Pin). 

As per claim 29 

Ice discloses: 

• disabling use of the transaction request identification includes the step of adding the transaction 
request identification to a spent list, the spent list being used to ensure a transaction request 
identification is not reused (column 6, lines 5-9); 

As per claim 30 

Ice discloses: 

• the EFT request sent to the financial institution comprises the user's banking information the 
value and merchant account banking information and sent to the financial institution system to 
transfer the funds according to a standard electronic fund transfer process (column 5, lines 61- 
67 & column 6, lines 1-4). 
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As per claim 31 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of the financial institution sending an insufficient funds reply if sufficient funds are not present, 
whereupon the transaction manager apparatus sends an insufficient funds reply to the recipient. 
However, Robinson, in at least Paragraph 0074 discloses "In yet another embodiment, the central 
database communicates with other financial databases to obtain financial information about the consumer 
relevant to determining whether or not the consumer has sufficient funds to cover the transaction." 
Paragraph 0075 discloses "If the transaction is declined, notice is sent to the local device 620, along with 
a reason the transaction was declined." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to check for sufficient funds in the users account. 

As per claim 32 

Ice discloses: 

• the confirmation message sent from the transaction manager apparatus to the recipient is the 
same as the confirmation of the transfer received from the financial institution (column 5, lines 
61-65) 

As per claim 34 

Ice discloses: 

• disabling re-use of the transaction request identification includes the formula for generating the 
single use transaction request identification including an increment in the next generated 
transaction identification request (column 6, lines 5-9) 
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As per claim 35 

Ice discloses: 

• the method of generating the transaction identification includes providing a check sum digit or 
character in the transaction request identification (column 4, lines 67) 

As per claim 36 

Ice discloses: 

• the transaction request identification is a number (column 4, lines 5-7). 

As per claim 37 

Ice discloses: 

• sending a confirmation of the transfer of funds from the transaction manager apparatus to the 
registered user (column 7, lines 20-24) 

As per claim 43 

Ice discloses: 

• sending the transaction request identification to the portable storage device comprises sending a 
plurality of transaction request identifications to the portable storage device and storing the 
identifications in the portable storage device (column 2, lines 24-33) 

As per claim 44 

Ice discloses: 

• sending a plurality of transaction request identifications may be provided to the user (claim 27) 
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As per claim 45 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of the transaction manager apparatus managing a plurality of registered users each having a 
plurality of transaction request identifications available for use in making a purchase. However, Robinson, 
in at least Paragraph 0012 discloses "The system of the invention comprises registration of a plurality of 
merchants, employees, and consumers so that these parties may conduct enrollment, transaction, and 
account access functions within the system." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to register and verify the merchant's and user's identity to the system. 

As per claim 47 

Ice discloses: 

• selecting the financial institution from a plurality of financial institutions according to the bank 
information retrieved according to the payment request after the payment request is validated 
(column 5, lines 61-65). 

As per claim 72 

Ice discloses: 

• recording a user identifier for each of at least one user registration in the transaction manager 
apparatus (column 4, lines 16-20 & column 2, lines 24-28). 

As per claim 73 

Ice discloses: 

• the payment request comprises recipient identifier indicative of recipient account for receipt for the 
funds transfer (column 5, lines 61-67 & column 6, lines 1). 
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As per claim 74 

Ice discloses: 

• retrieving the stored transaction request identification from within the storage of the transaction 
manager apparatus based on the received user identifier for determination whether the received 
transaction request identification is stored in a relationship with the received user identifier 
(column 5, lines 50-57). 

As per claim 75 

Ice discloses: 

• identifying the registered user when a remotely located electronic device of the registered user 
connects to the transaction manager apparatus (column 2, lines 17-23). 

As per claim 76 

Ice discloses: 

• generation of the single use transaction request identification occurs when the registered user is 
identified (column 4, lines 25-30 & column 4, lines 54-57). 

As per claim 77 

Ice discloses: 

• terminating the transaction when the received transaction request identifier is not validated 
(column 5, lines 50-53). It is inherent in Ice that if I match is not found then the decoded data is 
not returned to the gateway server. 

As per claim 79 

Ice discloses: 

• the confirmation message is sent from the transaction manager apparatus to a merchant 
electronic device of the recipient (column 5, 65-67 & column 6, lines 1). 
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As per claim 80 

Ice discloses: 

• the registered user causes the transaction request identification to be sent from a user electronic 
device to the merchant electronic device (column 5, lines 1-11). 

As per claim 81 

Ice discloses: 

• the merchant electronic device sends the payment request to the transaction manager apparatus 
(column 5, lines 12-16). 

As per claim 82 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of receiving an insufficient funds message from the financial institution computer system if 
sufficient funds are not present to conduct the transactional interaction, whereupon the transaction 
manager apparatus sends an insufficient funds message to the recipient. However, Robinson, in at least 
Paragraph 0074 discloses "In yet another embodiment, the central database communicates with other 
financial databases to obtain financial information about the consumer relevant to determining whether or 
not the consumer has sufficient funds to cover the transaction." Paragraph 0075 discloses "If the 
transaction is declined, notice is sent to the local device 620, along with a reason the transaction was 
declined." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to check for sufficient funds in the users account. 
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As per claim 84 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of inputting registration information of a prior registered user in to the transaction manager 
apparatus, the registration information including the banking information. However, Robinson, in Abstract 
discloses "System users register at least one biometric identifier, personal and/or business identity- 
verifying data, and financial account information." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to link the accounts with the registered user. 

As per claim 85 & 86 

Ice discloses: 

• identifying a registered user when a remotely located electronic device of the registered user 
connects to the transaction manager apparatus (column 2, lines 17-23); 

• generating a single use transaction request identification with a transaction manager (column 4, 
lines 54-57) 

• receiving at the transaction manager apparatus a secret code known to and provided by the 
identified registered user (column 4, lines 7-11: Pin); 

• storing in the transaction manager apparatus the generated single use transaction request 
identification in association with the user identifier of the identified registered user, the secret 
code and banking information of the identified registered user for use by a financial institution 
computer system in association with the user identifier; (column 4, lines 54-57) 

• sending the generated single use transaction request identification to the registered user from the 
transaction manager (column 4, lines 60-63); 

• receiving at the transaction manager apparatus a payment request comprising a request 
identifier, a user identifier, a recipient identifier, a value and a test code; (column 5, lines 43-53 
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& column 5, lines 61-64) Ice does not explicit state a value but it is inherent in the teaching that 
the transaction cannot be approved without a value; 

• retrieving the stored transaction request identification and the secret code from within the 
transaction manager apparatus based on the received user identifier (column 6, lines 33-37) ; 

• determining the validity of the received request identifier by the transaction manager apparatus 
checking whether the received request identifier is the same as or based on the retrieved 
transaction request identification and whether the test code is the same as or based on the secret 
code, and disabling re-use of the single use transaction request identification when the received 
request identifier is validated, and terminating the transactional interaction when the received 
request identifier is not validated; (column 5, lines 43-56 & Column 6, lines 5-9); 

• retrieving the stored banking information of the registered user in the stored data relationship with 
the received user identifier (column 5, lines 50-57); 

• sending an EFT request to a financial institution system to transfer the value in funds from the 
registered user to the recipient, only if the received payment request is valid, the EFT request 
including the banking information, (column 5, lines 61-65); 

• receiving at the transaction manager apparatus a first confirmation message from the financial 
institution computer system when the transactional interaction has been successfully completed 
according to the EFT request message; and (column 5, lines 61-65) 

• sending a second confirmation message from the transaction manager apparatus to a second 
electronic device when the first confirmation message is received (column 5, lines 61-65). 

Ice does not disclose the following, however Robinson does: 

• recording a user identifier for each of a plurality of user's at least one user registration in a 
transaction manager apparatus (Abstract); 

• a registered user (Abstract) 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice with the technique of Robinson because it is a quick, easy and 
convenient way to register and verify the user's and merchant's identity to the system. 
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As per claim 87 

Ice discloses: 

• wherein the payment request is constructed from the user identifier and transaction request 
identifier received from the user (column 4, lines 25-30). 

As per claim 88 

Ice discloses: 

• the payment request is also constructed from a user provided secret component sent to the 
merchant device (column 4, lines 7-11: Pin). 

As per claim 89 

Ice discloses: 

• wherein the other account is a financial institution account also held by the registered user 
(column 3, lines 60-65). 

As per claim 90 

Ice discloses: 

• wherein the EFT request comprises destination bank account information selected from the 
stored banking information according to the identifier of the other account (column 3, lines 60- 
65). 

As per claim 92 

Ice discloses: 

• wherein the EFT request comprises destination bank account information which is selected from 
stored banking information of a plurality of recipients according to a recipient identifier in the 
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payment request after the payment request is validated (column 5, line 50-53 & column 5, lines 
57-60). 

19. Claims 3-5, 33, 38-42, 83 & 91 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ice in 

view of Robinson and in further view of Official Notice. 
As per claim 3 & 4 

With regard to the limitation of the transaction request identification is generated using a random 
number or a formula, Ice in column 4, lines 63-67 discloses FIG. 2 is a pictographic view of the 16-digit 
single-use credit card number 52. The first six digits are an ISO BIN number identifying the payment 
server 34. The following nine-digits are a transaction number assigned by the payment server 34. The 
final digit is a checksum digit. Ice does not specifically state a random number or a formula. However, the 
Examiner takes Official Notice that it is old and well known in the banking arts to generate transaction 
numbers by formula or a random number generator. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is a 
quick, easy and convenient way to generate transaction numbers that are not repeated which reduces the 
chances of fraud from predicting the transaction numbers. 

As per claim 5 

With regard to the limitation of the transaction request identification is generated using a random 
number and a formula, Ice in column 4, lines 63-67 discloses FIG. 2 is a pictographic view of the 16-digit 
single-use credit card number 52. The first six digits are an ISO BIN number identifying the payment 
server 34. The following nine-digits are a transaction number assigned by the payment server 34. The 
final digit is a checksum digit. Ice does not specifically state a random number and a formula. However, 
the Examiner takes Official Notice that it is old and well known in the banking arts to generate 
transaction numbers by formula and a random number generator. 
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It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is a 
quick, easy and convenient way to generate transaction numbers that are not repeated which reduces the 
chances of fraud from predicting the transaction numbers. 

As per claim 33 

With regard to the limitation of confirmation message sent from the transaction manager to the 
merchant is created by the transaction manager apparatus and is different to the confirmation of the 
transfer received from the financial institution; Robinson, in at least Paragraph 0074 discloses "In yet 
another embodiment, the central database communicates with other financial databases to obtain 
financial information about the consumer relevant to determining whether or not the consumer has 
sufficient funds to cover the transaction." Paragraph 0075 discloses "If the transaction is declined, notice 
is sent to the local device 620, along with a reason the transaction was declined." However, the 
Examiner takes Official Notice that it is old and well known in the banking arts to provide a different 
confirmation message to the merchant. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is an 
easy and convenient way to notify the transaction has been completed. 

As per claim 38-40 

With regard to the limitation of the confirmation sent to the registered user is an e-mail message, the 
transaction request identification is to the registered user via the Internet and the transaction request 
identification is sent to the registered user by a telephone interface system; Robinson in paragraph 0045 
discloses "Parties interested in enrolling in the invention's system further have the option to pre-enroll, 
that is provide a partial enrollment, by providing only a portion of the required enrollment information, for 
the invention's services via a computer 104, a kiosk 128, or a wireless device 122, which is connected to 
a network, preferably but without limitation the Internet, which is connected to the invention's central 
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database 102." However, the Examiner takes Official Notice that it is old and well known in the banking 
arts to provide a confirmation messages through email, the internet or the phone. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is a quick 
and easy way of providing confirmation of the completion of transactions. 

As per claim 41 & 42 

With regard to the limitation of sending the transaction request identification to the registered user 
comprises sending the transaction request identification to a portable storage device held by the user and 
sending the transaction request identification from the portable storage device to the recipient. Ice in 
column 3, lines 22-31 discloses "This apparatus includes a personal computer terminal, generally 
indicated as 10, which is connected by conventional means to a public network 12, such as the Internet, 
operating over a public switched telephone network. The personal computer terminal 10 includes a 
personal computer 14, a keyboard 16, a display unit 18, all of which may be conventional devices. The 
personal computer 14 includes a processor 20 and a storage device 22, which is used to store data and 
to store instructions forming a program executing in the processor 20." Column 3, lines 36-41 discloses 
"The personal computer terminal 10 is also particularly configured to facilitate the generation and 
transmission of encrypted information, facilitating the use of the terminal 10 to purchase products and 
services and to direct bank transactions over the public network 12, while consistently maintaining a high 
level of security." Ice does not explicitly disclose a portable storage device. However, the Examiner takes 
Official Notice that it is old and well known in the arts that personal computers are also portable storage 
devices. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is a quick 
and easy way of providing confirmation of the completion of transactions. 
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As per claim 83 

With regard to the limitation of sending a plurality of transaction request identifications to a user's 
electronic device in one transfer; Ice in column 2, lines 24-30 discloses "The data base stores first and 
second data structures. The first data structure includes a first plurality of single-use credit card numbers, 
a serial number of an encryption unit associated with each single-use credit card number in the first 
plurality of single-use credit card numbers and found by locating the single-use credit card number in the 
plurality of single-use credit card number." Ice does not explicitly disclose sending to an electronic device 
in one transfer. However, the Examiner takes Official Notice that it is old and well known in the banking 
arts to provide a plurality of transaction numbers to a user for one-time use. 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is an 
easy and convenient way to send transaction requests to the user. 

As per claim 91 

With regard to the limitation of wherein the generated single use transaction request identifier is only 
sent to the registered user once the registered user is identified to the satisfaction of the transaction 
manager apparatus, wherein identifying the registered user occurs when a remotely located electronic 
device of the registered user connects to the transaction manager apparatus. Ice in column 5, line 50-53 
discloses "When a match is found, the payment server reads the serial number associated with the 
single-use credit card number in the data structure 50, and searches the data structure 48 for this serial 
number" & column 5, lines 57-60 discloses "this decoded data is returned to the gateway server 58 which 
provided the single-use credit card number, providing the actual number of the credit card 28 in a 
conventional format." Ice does not explicitly disclose identifying the registered user occurs when a 
remotely located electronic device of the registered user connects to the transaction manager apparatus. 
However, the Examiner takes Official Notice that it is old and well known in the banking arts for a 
terminal to ask for a user verification ID before the user is able to access the terminal. 
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It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Official Notice because it is an 
easy and convenient way to prevent fraud. 

20. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ice in view of Robinson and 

in further view of Lapsley et al. US 2001/0000535. 
As per claim 13 

Ice discloses the limitations as shown in the rejection of Claim 1 above. Ice does not disclose the 
limitation of the transaction manager apparatus confirming the bank information with the user's financial 
institution before creation of the transaction manager user account. However, Lapsley, in claim 157 
discloses "In one embodiment, the DPC validates the financial account data submitted during registration. 
This involves making certain that the financial account being registered is a valid account." 

It would have been obvious to one of ordinary skill in the art at the time of the invention to 
[combine/modify] the method of Ice & Robinson with the technique of Lapsley because it is an easy and 
convenient way to eliminate errors in transactions when using the system. 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth 
in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from 
the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date 
of this final action and the advisory action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on the date the advisory action 
is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to KITO R. ROBINSON whose telephone number is (571) 270-3921. The examiner can 
normally be reached on Monday-Friday 7:30am-5:00pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Charles Kyle can be reached on (571) 272-6746. The fax phone number for the organization where this 
application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) 
at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative 
or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272- 
1000. 

/Kito R Robinson/ 
Examiner, Art Unit 3695 

28 October 2010 

/Charles R. Kyle/ 

Supervisory Patent Examiner, Art Unit 3695 



